home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
TeX 1995 July
/
TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO
/
tex-k
/
tex-k-archive.past
/
tex-k-archive.gz
/
tex-k-archive
/
000064_fj@iesd.auc.dk_Sun Oct 17 21:35:02 1993.msg
< prev
next >
Wrap
Internet Message Format
|
1994-10-11
|
2KB
Received: from iesd.auc.dk by cs.umb.edu with SMTP id AA09154
(5.65c/IDA-1.4.4 for <tex-k@cs.umb.edu>); Sun, 17 Oct 1993 15:35:34 -0400
Received: from loke.iesd.auc.dk by iesd.auc.dk with SMTP id AA13119
(5.65c8/IDA-1.5/MD); Sun, 17 Oct 1993 20:33:35 +0100
Received: by loke.iesd.auc.dk id AA27138
(5.65c8/IDA-CLIENT/MD); Sun, 17 Oct 1993 20:35:02 +0100
Date: Sun, 17 Oct 1993 20:35:02 +0100
From: Frank Jensen <fj@iesd.auc.dk>
Message-Id: <199310171935.AA27138@loke.iesd.auc.dk>
To: karl@cs.umb.edu
Cc: tex-k@cs.umb.edu
In-Reply-To: <199310131932.AA01949@terminus.cs.umb.edu> (karl@cs.umb.edu)
Subject: Re: Speed of (recursive) search in the Kpathsearch library
Karl> Frank's idea of using ls -R output to speed up the file searching is
Karl> interesting, but, as he says, has the disadvantage of maintaining
Karl> another file that will inevitably be out of date.
Well, I wouldn't put it as strongly as ``inevitably be out of date.''
I'm sure, I would remember to keep the file up-to-date, or at least
diagnose the problem if I forget it :-)
I would only use this mechanism for the system directories (which
rarely change), not for my private directories. This is simply
because my private directories are small, and a database for these
files won't give much speed-up.
Anyway, one can always ignore this feature if one so desires.
Karl> Maybe another caching strategy would work well enough and wouldn't have
Karl> that lossage: when a file is found in a given directory, move that dir
Karl> to the head of the list. My impression is that most jobs use a lot of
Karl> files in a few directories.
Hmm, let me see. Inspecting the LaTeX log file from my latest paper,
I see that 12 files are being read; they are distributed in 5
directories, one of which is the current directory from where 5 files
are read. I note that the files read from the current directory are
found quickly, whereas the other files takes somewhat longer to find.
However, quite long time elapses before the first file is read; this
is primarily the time taken to set up the directory list.
This indicates to me that the heuristic of rearranging the directory
list as Karl suggests won't work well enough in practice.
I therefore strongly suggest that such a feature be built into the
Kpathsearch library, perhaps as a compile-time option. I will even
volunteer to code it (since I already have a half-finished version).
/Frank